home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-pem-mime-alternative-00.txt < prev    next >
Text File  |  1993-10-26  |  11KB  |  236 lines
  1. Network Working Group                    Internet Engineering Task Force
  2. Internet Draft                       Privacy Enhanced Mail Working Group
  3. <draft-ietf-pem-mime-alternative-00.txt>                  J. I. Schiller
  4.                                                                      MIT
  5.                                                             October 1993
  6.  
  7.           An Alternative PEM MIME Integration
  8.  
  9. Status of this Memo
  10.  
  11.    This  document  is an   Internet Draft.  Internet Drafts  are working
  12.    documents  of the Internet Engineering  Task Force (IETF), its Areas,
  13.    and its  Working Groups. Note  that other groups may  also distribute
  14.    working documents as Internet Drafts.
  15.  
  16.    Internet Drafts  are draft  documents valid  for   a maximum  of  six
  17.    months. Internet   Drafts may be updated,  replaced,  or obsoleted by
  18.    other documents at any  time. It is not  appropriate to  use Internet
  19.    Drafts as reference material or to cite them other than as a "working
  20.    draft" or "work in progress."
  21.  
  22.    Please check  the  I-D abstract listing  contained  in  each Internet
  23.    Draft  directory to learn  the  current status of   this or any other
  24.    Internet Draft.
  25.  
  26.    Distribution of  this memo is  unlimited. Please send comments to the
  27.    <pem-dev@tis.com> mailing list.
  28.  
  29.    This is the second document  to describe a  mechanism to enclose MIME
  30.    messages  within PEM and vica versa.  This document is an independent
  31.    effort to be  considered as an  alternative to the previous document.
  32.    This  is *not* a revision  of that document and the  authors of it do
  33.    not necessarily endorse the approach described here.
  34.  
  35. Introduction
  36.  
  37.    This document  describes a mechanism  for providing  Privacy Enhanced
  38.    Mail (PEM) functionality within the context of MIME messages.
  39.  
  40. Background
  41.  
  42.    MIME (RFC1341-1342)   and PEM    (RFC1421-1424) have  taken  separate
  43.    evolution paths. Specifically    PEM was designed  and specified   to
  44.    handle RFC822  (non-MIME) messages. The goal of  this document  is to
  45.    describe a  method  for using PEM  to  protect MIME messages,  and to
  46.    define a way to enclose PEM processed messages within MIME messages.
  47.  
  48.    To accomplish these goals requires an  additional profile for RFC1421
  49.    (Content-Domain: MIME) and the definition of a new MIME "application"
  50.    (application/pem-1421).
  51.  
  52.    There are  four possibilities for interaction  between PEM  and MIME.
  53.    They are:
  54.  
  55.    * A MIME   message transporting an  RFC1421 PEM  message which itself
  56.    contains an RFC822 message (Content-Domain: RFC822).
  57.  
  58.    * A MIME  message  transporting an  RFC1421 PEM  message which itself
  59.    contains a MIME object (Content-Domain: MIME).
  60.  
  61.  
  62.  
  63. Expires: April 28, 1994                                         [Page 1]
  64. Network Working Group                    Internet Engineering Task Force
  65. Internet Draft                       Privacy Enhanced Mail Working Group
  66.                                                           J. I. Schiller
  67.                                                                      MIT
  68.                                                             October 1993
  69.  
  70.    * A PEM  message  which contains a  RFC822  message (as  specified by
  71.    RFC1421).
  72.  
  73.    *  A PEM message  which contains  a MIME message  or object (Content-
  74.    Domain: MIME).
  75.  
  76. Definition of "Content-Domain: MIME" within an RFC1421 PEM message
  77.  
  78.    When  a PEM message  contains a MIME object, as  opposed  to a simple
  79.    text message,   the value  of  the  Content-Domain  field of the  PEM
  80.    headers shall be the string "MIME".
  81.  
  82.    An RFC1421 PEM message of  Content-Domain "MIME" shall contain a MIME
  83.    "object" that begins with a "Content-Type" MIME header. The PEM body,
  84.    upon completion of  successful PEM  processing is  handed to a   MIME
  85.    interpreter for  further  processing. Content-Domain "MIME"  messages
  86.    may be protected with   either ENCRYPTED, MIC-ONLY or  MIC-CLEAR  PEM
  87.    services. However if MIC-CLEAR is chosen, the  MIME content should be
  88.    in a canonical 7bit form.
  89.  
  90.    In  other  words, if the  enclosed  MIME object   is encoded  in such
  91.    fashion as  to be  7bit   transportable, then MIC-CLEAR  may  be (and
  92.    perhaps   should  be) used. Other   non-encrypted  messages should be
  93.    encoded via the MIC-ONLY mechanism.
  94.  
  95. Enclosing a PEM message within a MIME object
  96.  
  97.    An RFC1421 PEM message may be enclosed  in a MIME message by defining
  98.    it to be of Content Type "application/pem-1421"  by preceding the PEM
  99.    processed body with:
  100.  
  101.                Content-Type: application/pem-1421
  102.  
  103.    Note that the   application subtype is  defined to  be "pem-1421" and
  104.    that the  representation *must* be text/plain; charset=us-ascii. This
  105.    is because these are  correct  characterizations  of what a   RFC1421
  106.    message appears as.
  107.  
  108. The behavior of a MIME mail reader with PEM capability
  109.  
  110.    A MIME mail reader with PEM capability will  be able to fully process
  111.    a MIME message which includes a PEM portion (which  may either be the
  112.    entire message or only part of a multi-part message).
  113.  
  114.    The MIME reader  will process a message which  contains a PEM portion
  115.    as  it  would    any   other  MIME  message.   Upon    encountering a
  116.    "application/pem-1421"  body part, it  will  invoke PEM processing on
  117.    the  enclosed  PEM message. If  the  PEM message contains  a Content-
  118.    Domain "MIME"    body,   it will   invoke  MIME  recursively   on the
  119.    successfully processed PEM body. If the Content-Domain is RFC822, the
  120.    PEM software will  either display the enclosed  text,  or prepend the
  121.    necessary headers such that it can be fed to a MIME reader which will
  122.    treat it as an RFC822 mail message.
  123.  
  124.  
  125.  
  126. Expires: April 28, 1994                                         [Page 2]
  127. Network Working Group                    Internet Engineering Task Force
  128. Internet Draft                       Privacy Enhanced Mail Working Group
  129.                                                           J. I. Schiller
  130.                                                                      MIT
  131.                                                             October 1993
  132.  
  133. The behavior of a MIME mail reader without PEM capability
  134.  
  135.    A MIME mail reader will  process a MIME  message with PEM contents as
  136.    any other MIME message. If  an  application/pem-1421 object is  found
  137.    and the MIME  reader does not support  PEM, then the MIME  reader may
  138.    handle the enclosed PEM message in the  same or similar fashion as it
  139.    handles any  other application subtype  for which  it  has no support
  140.    software.
  141.  
  142. The behavior of a non-MIME but PEM capable mail reader
  143.  
  144.    A   PEM mail reader  that  does not understand   MIME will be able to
  145.    process a MIME/PEM message provided that the  message itself is a PEM
  146.    message. In other words, if the whole message is PEM processed as the
  147.    last step prior  to  transmission, then  a PEM capable,  but non-MIME
  148.    capable mail reader will be able to process the  PEM message and then
  149.    display the enclosed MIME object in the same  fashion that a non-MIME
  150.    mail reader handles a MIME (but non-PEM) message today.
  151.  
  152.    It is likely that a non-MIME compliant mail  reading agent may not be
  153.    able  to parse  a  MIME  message  in order  to  discover an  enclosed
  154.    "application/pem-1421" component containing a PEM message. However an
  155.    end-user may be able to manually  reformat the incoming message so as
  156.    to make it amenable to PEM processing.
  157.  
  158. Discussion
  159.  
  160.    Prior  approaches   to integrating  PEM  and  MIME  have  suggested a
  161.    significant  departure from the  RFC1421 PEM encapsulation mechanism.
  162.    Specifically it has been recommended that PEM messages be represented
  163.    as MIME multi-part messages. One part of the multi-part would contain
  164.    what in RFC1421 is described as the PEM headers,  and the other would
  165.    contain  the  PEM body   that  is protected  by the    PEM mechanisms
  166.    specified in the PEM header part.
  167.  
  168.    This document intentionally does not recommend such an approach. This
  169.    is because it is important for MIME interpreters  to *not* reach down
  170.    into the  structure  of a  PEM body   until PEM  processing  has been
  171.    performed. The  reason  for  this  requirement has  to   do  with the
  172.    requirement   that PEM  body   parts  be  immutable  so that  digital
  173.    signatures computed  on them can  be verified. If  a PEM body part is
  174.    decomposeable by MIME readers,  then it is  quite possible  that MIME
  175.    gateways  could reassemble PEM body  parts  in a fashion semantically
  176.    equivalent to the original message, but sufficiently different (i.e.,
  177.    different in  one bit is sufficient)  to cause signature verification
  178.    to later fail.
  179.  
  180.    It is important   to   understand that  the  signature   verification
  181.    requirement mandates that  PEM  messages be  carried within  MIME  as
  182.    "application" objects and   not  as "message",  "multipart"  or other
  183.    types  of body parts. Once this  is recognized,  it no longer matters
  184.    whether or not the object within  the "application" enclosure appears
  185.    to be a MIME object upon visual inspection, for it is now outside the
  186.    realm of what a MIME interpreter may attempt to parse without the aid
  187.    of the application processor (PEM in this case).
  188.  
  189. Expires: April 28, 1994                                         [Page 3]
  190. Network Working Group                    Internet Engineering Task Force
  191. Internet Draft                       Privacy Enhanced Mail Working Group
  192.                                                           J. I. Schiller
  193.                                                                      MIT
  194.                                                             October 1993
  195.  
  196.    By  using the RFC1421 based encapsulation  technology we benefit from
  197.    the experience gained  in  debugging existing PEM implementations  as
  198.    well as ease backward compatibility with non-MIME based PEM agents.
  199.  
  200. Examples
  201.  
  202.    Date: Sun, 30 May 93 23:59:39 EST
  203.    From: jis@MIT.EDU (Jeffrey I. Schiller)
  204.    To: pem-dev@tis.com
  205.    Subject: Example PEM MIME Interaction
  206.    MIME-Version: 1.0
  207.    Content-Type: application/pem-1421
  208.  
  209.    -----BEGIN PRIVACY-ENHANCED MESSAGE-----
  210.    Proc-Type: 4,MIC-CLEAR
  211.    Content-Domain: MIME
  212.    Originator-Certificate: MIIB+jCCAWMCAQIwDQYJKoZIhvcNAQECBQAwSj...
  213.    Issuer-Certificate: MIIB+jCCAWMCAQQwDQYJKoZIhvcNAQECBQAwRDELMA...
  214.    MIC-Info: RSA-MD5,RSA,dlSRMLFiwcK7FDvFef8gJfLWwMM4uxMSNtKGlLz9xxw
  215.     fAyvaFuzp85davcwX4q7EImDs4K46Uwh0oL2GueLnv6b4s1gg25mMg/Y5Bd7/HaE
  216.     cvkV77tKWGXZrDGEgGSDA
  217.  
  218.    Content-Type: text/plain; charset=us-ascii
  219.  
  220.    This is a test message.
  221.    -----END PRIVACY-ENHANCED MESSAGE-----
  222.  
  223. Author's Address
  224.  
  225.    Jeffrey I. Schiller
  226.    Massachusetts Institute of Technology
  227.    MIT Room E40-311
  228.    1 Amherst Street
  229.    Cambridge, MA 02139
  230.    U.S.A.
  231.    Tel:    +1 (617) 253-0161
  232.    Fax:    +1 (617) 258-8736
  233.    Email:  jis@mit.edu
  234.  
  235.  
  236.